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Incorporating Manual 
and Autonomous 
Code Generation 


Code can be generated manually or using code-generations soft- 
ware took, huthow do you interpret the two 7 This article looks, at 
a design methodology that combines object-oriented design with 
autonomy code generation for attitude control flight software. 
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R ecent improvements in space flight computers including 
floating-point hardware, ample EEPROM/RAM, and plen- 
ty of CPU power are allowing software engineers to spend 
more time engineering the applications software. In my 
case, the application is the attitude control flight software 
for an astronomical satellite called the Microwave 
Anisotropy Probe (MAP). The MAP flight system is being designed, 
developed, and integrated at NASA’s Goddard Space Flight Center. The 
MAP controls engineers are using Integrated Systems Inc.’s MATRIXx 
for their controls analysis.' In addition to providing a graphical analysis 
environment, MATRIXx includes an autonomoi* code generation facil- 
ity called Autocode. As the software engineer I was faced with the task of 
designing the interface between the manually generated flight software 
and the autonom wa a f y ^generated C code. This article examines the 
forces that shaped the final design and describes three highlights of the 
design process: 


• Defining the manuatio-autonoindm code interface. The design shields 
the controls engineers from the flight environment and defines a 
robust functional interface that has had little change 

♦ Applying object-oriented design to the manual flight code Modeling the 
control modes using inheritance provides a simple and robust design 

* Implementing the objeci-onenltd design in C. The implementation of the 
inheritance hierarchy is not a generic object-oriented implementa- 
tion in C. but it proved to be adequate for MAP’s requirements 
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Attitude determination uses sensor measurements to update the 
onboard estimated attitude which is supplied to the controller 

subsystem. 


MAP attitude control 

Figure l shows a simplified high-level 
block diagram of MAPs flight control 
software. Sensors measure spacecraft 
position and rates. Attitude determi- 


nation uses sensor measurements to 
update the onboard estimated attitude 
which is supplied to the controller 
subsystem. The desired spacecraft atti- 
tude is either supplied by mode man- 
agement or internally computed by 
command generation. Attitude error 
computes control errors for the con- 
trol law, based on a combination of 
sensor measurements, estimated atti- 
tude, and commanded attitude. The 
control law computes control torques 
which are output to the actuators. The 
shaded portion identifies the con- 
troller subsystem which has been des- 
ignated for autocode. (The remainder 
of the article will use autocode to refer 
to both the tool and the autonomous- 
4y generated code.) 

To understand the object-oriented 
design within the context of this arti- 
cle, two other features of MAP must be 
described: the sensors and actuators, 
and the operational modes. MAP uses 
the following sensors and actuators for 
attitude determination and control: 


V 

/ 


• Inertial reference units (IRU) — 
Measure angular changes in MAP’s 
position. Spacecraft body rates are 
derived from the incremental 
angular measurements 

• Digital sun sensor (DSS) — Provides 
accurate measurements {<0.01 
degrees) of the sun's position with- 
in a 64 degree square Held of view 

• Coarse sun sensors (CSS) — Provide 

coarse measurements (<10 
degrees) of the sun’s position. The 
CSSes are mounted to provide 4 p 
steradian coverage f > 

• Star tracker (ST) — Provides an esti- 
mated attitude derived from star 


measurements 

• Propulsion control system (PCS) — 
Provides external torque to the 
spacecraft via hydraaine-fueled 
thrusters 

• Reaction wheel assembly (RWA) — 
Provides spacecraft momentum 
control via three reaction wheels 

MAP uses five operational modes to 
achieve its mission goals. Modes are 
defined in terms of operational objec- 
tives, spacecraft control objectives, 
and performance criteria. Each mode 
specifies a set of sensors and actuators 


ning pattern. Observing is the only 
mode used for collecting science 
data 

• Delta-V (DV) — Uses IRUs and the 
PCS to perform spacecraft maneu- 
vers. Delta-V is used for trajectory 
management to get to the Sun- 
Earth L2 point approximately 1.5 
million km from the Earth (away 
from the sun) and for L2 station- 
keeping 

• Delta-H (DH) — Uses IRUs and the 
PCS to perform momentum 
unloading 




Flight control software block diagram'. V 
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and a control subsystem configura- 
tion. MAP defines the following 
modes: 

• Sun Acquisition (SA) — Uses IRUs, 
CSSes, and the RWA to acquire a 
sun-pointing, power, and thermally 
safe attitude within 20 minutes 
from any initial attitude 

• Inertial (IN) — Uses IRUs, DSS, ST, 
and the RWA to acquire and hold a 
fixed commanded auitude 

• Observing (OB) — Uses IRUs, DSS. 
ST, and the RWA to perform a scan- 


Scope the interface 

Business, as well as technical forces, 
shaped the boundary of the autocode 
subsystem. On previous missions, a 
high fidelity simulation (HIFI) written 
in Fortran was used to develop the 
control algorithms which were docu- 
mented via a hand-written algorithm 
document. Autocode changes this par- 
adigm by forcing the HIFI design to 
assimilate enough of the FSW environ- 
ment to allow the autocode to be used 
directly by the FSW. Autocode’s scope 
dictates how much of the flight envi- 
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ronmeni needs to be modeled by 
HIFI. 

M/VP's FSW tasking architecture is 
built on an existing “software bus" 
which placed limits on autocodes 
scope. The software bus provides stan- 
dardized packet-based intertask com- 
munication and insulates applications 
from the real-time operating system. 
This heritage immediately limited 
autocode to an intra-task scope and 
ISI’s RTOS, pSOSvstem, was not even 
considered. The flight controller pic- 
tured in Figure 1 is suitable for a single 
task because all of its components exe- 
cute at 1 Hz and have fairly strong data 
cohesion. 

Additional design decisions further 
narrowed the autocode scope to the 


shaded controller subsystem. It has a 
small and simple set of inputs and out- 
puts. All I/O can be performed in the 
spacecraft body frame. The controller 
subsystem docs not directly interface 
to the following FSW subsystems: sen- 
sor/ actuator hardware, ground com- 
mand inputs, error message output, 
and fault detection. Therefore, the 
HIFI does not need to emulate these 
FSW facilities. Attitude determination 
shares many of the same attributes as 
the controller subsystem with respect 
to being suitable for autocode, but it 
was not chosen for autocode since 
MAT could adapt an existing attitude 
determination subsystem from a previ- 
ous mission. 

Limiting the scope of autocode to 
the controller subsystem coincides 
with Goddard's business philosophy as 


well MAP is Goddard’s first mission to 
use an autonomous code generator 
for its FSW, and prior to MAP, 
Goddard has had minimal experience 
with ISI 's code generator. Coupled 
with MAP’s short development sched- 
ule. this small, well-contained subset 
of the FSW is a good way to minimize 
the risk factor. In addition, the con- 
troller subsystem has a high algorithm- 
to-Iogic ratio which maximizes 
autocode s benefits of speeding up the 
process of documenting and coding 
the algorithms from HIFI and in 
reducing errors during the translation 
process. However, MAP’s return on 
investment is limited due to the learn- 
ing curve and the small scope of the 
autocode relative to the size of the 
entire FSW effort. 


Autonomous 
code 

environment 

MAP is using 
autocode's basic fea- 
tures since we are gen- 
erating discrete pro- 
cedures without mul- 
titasking. The output 
of autocode is simply 
a collection of C func- 
tions. Using 

autocode’s template language, I have 
customized autocode to output each 
function in' a separate source file with 
a corresponding header file. This 
helps isolate and identify exactly what 


code has changed as a result of an 
algorithm change. This strategy may 
he useful after our scheduled develop- 
ment period when we need to access 


the testing effort required to verify a 
late algorithm change. 

The collection of C functions can 
be conceptualized as a single object. 
Figure 2 show’s a class diagram repre- 
sentation of the autocode interface 
that must be managed by the manual- 
ly coded FSW. Only two autocode 
functions need to be called 
Initialize needs to be called once 
during system initialization. Execute is 
called each control cycle and it man- 
ages calling the subordinate autocode 
functions. The Input structure is 
loaded prior to calling Execute and 
the Output structure contains the 
results. The contents of Input and 
Output are as shown in Table 1 

Object-oriented design 

As I mentioned, control modes specify 
a set of sensors and actuators to be 
used and the control subsystem con- 
figuration. Inheritance works particu- 
larly well to abstract common attribut- 
es and behavior shared among the 
control modes. Figure 3 show the 
inheritance diagram used as a model 
for the manually coded portion of the 
controller. The modes are first classi- 
fied according to what actuator is used 
for control and each actuator con- 
troller is subdivided into specific con- 
trollers. 

The base controller class provides 
three functions: New, Delete, and 
MonitorPerformance. The italicized 
functions are virtual functions and 


descendants provide the implementa- 
tion. New and Delete arc used to 
instantiate and destroy controllers, 
respective!). Noni torPer f ormance is 
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Notation: 


Cliss. N.imo 


Parameters j 

Methods ! 

. j 


Controller Subsystem 


Parameters 

Initialize 

Execute (Input, Output) 
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Sun Acquisition 


Virtual Function Table 

Constructor 

Destructor 

IsModeComplete 

UpdateState 


Identifier 

Stateldentlfler 

TimelnState 

SysMonMagnitude 

VirtualFunctionTable 


New 

Delete 

M o ni torPerf orman ce 
CompItetTorque 
UpdateState 
IsModeComplete 
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RWA Torque Cmds 

Constructor 

Destructor 

CompleteTorque 


PCS Thruster Cmds 
Bum Duration 

Constructor 

Destructor 

CompleteTorque 



Virtual Function Table 


Constructor 
Destructor 
Perform slew 
IsModeComplete 
UpdateState 


Observation 


Virtual Function Table 

Constructor 

Destructor 

IsModeComplete 

UpdateState 





Virtual Function Table 
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Target Momentum 



Virtual Function Table 

Constructor 


Constructor 

Destructor 


Destructor 

IsModeComplete 


IsModeComplete 

UpdateState 


UpdateState 


similar to a protected function in C++ 
and is used by descendant classes to 
monitor body rates, body rate errors, 
and attitude errors. Notice that 
ComputeTorque is implemented by 
the RWA and PCS controllers and not 
the five control modes. Compute- 
Torque calls autocode’s Execute func- 
tion, passing mode-specific control 
flags that are defined when a mode is 
constructed. Finally, IsModeComplete 
and UpdateState are implemented by 
each controller because they address 
state information that is unique to 
each controller. 

Since ihe base Controller class 
defines a common interface for all of 
the controllers, the code that manages 
the controllers is identical regardless 
of which conirollcr is executing. This 


proved very useful during unit testing 
since the test driver is identical to the 
FSW that manages the controllers. 
The Input and Output data structures 
used by the autocode are managed by 
both the Controller class and the RWA 
and PCS controller classes. Although 
management of the autocode inter- 
face is not encapsulated within a single 
class, it has proven to be a robust 
implementation, resilient to ripple 
effects due to changes in the autocode 
interface. Inheritance has also kept 
the functions relatively small and sim- 
ple so they have been easy to under- 
stand and lest. 

Implementation 

I did not take a general approach 
toward implementing object-oriented 


concepts in C. Virtual function tables 
were manually created and no dynam- 
ic memory allocation is used. Listing 1 
shows the essential data type defini- 
tions for the abstract controller class. 
The ATT CT L_ RWA and 

ATTCTL_PCS structures are used by 
the RWA and PCS controllers and 
access control is managed by the pro- 
grammer. In C++ these data structures 
would be defined as part of the RWA 
and PCS classes and the compiler 
would enforce data access control. 
The New function loads the 
ATTCTL_VTBL structure. A pointer 
to a controller’s virtual function table 
is supplied as a parameter to New. This 
implementation relics on the fact that 
multiple controllers cannot exist 
simultaneously 
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autocode followed by a call to the 
RWA or PCS Compute Torque virtual 
function. The RWA or PCS function 
processes the mode-dependent por- 
tion of Output as shown in 
AttCtl__RwaCo«nputeTorque. Finally, the 
mode independent portion of Output 
is processed by AttCtl's ComputeTorque. 

Some downsides exist to using the 
autocode in this fashion. The Input 
structure to autocode includes mode 
control flags which summarize infor- 
mation that is already captured by the 
class inheritance structure. Autocode 
contains logic to execute different 
forms of the controller based on the 
Input mode control flags. If the 
entire system were designed as a 
whole, the conditional blocks of the 
autocode controller would exist as 
functions within the individual con- 
troller classes. 

Another drawback to AutoCode is 
that it can be inefficient with respect 
to both memory and speed. Autocode 
works on each graphical element as it 
produces code. Many blocks are trans- 
lated into functions with large para- 
meter lists. Functions are good for 
traceability from code to design but 
may be bad for code optimization. 
There is an inline procedural block 
feature that allows blocks to be gener- 
ated inline with the current blocks 
code. This helps, but lumping code 
into a single function is not always 
desirable. For MAP, we are generating 
each “superb lock" as a separate func- 
tion contained in a separate file. This 
allows algorithmic changes to be con- 
figuration managed at the source file 
level. The additional function over- 
head is acceptable since we aren’t 
close to our CPU or memory budgets. 

MAP is also taking a conservative 
approach with respect to testing the 
autocode. To maximize savings in test 
time, autocode would be treated as a 
black box during FSW unit testing 
The analyst would test the algorithms 

Listing 2 shows ComputeTorque’s of the Input structure that are static in HIFI and the autocode would be 

implementation. AttCU_Compute- during a controller’s lifetime are passed to the build/acceptance test 

Torque loads the dynamic portions of loaded when a controller is construct- icam after being integrated with the 

the autocode Input data. The portions ed. AttCtl_ComputeTorque invokes the rest of the FSW MAP has altered this 
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/* Virtual Function Table */ 
typedef void ( *ATTCTl w C0NSTRUCT0R) (void *>; 

typedef void (^naiwCO^VT^JORQUE) (void); 

typedef void UATTCTl^ESTRUCTOR) (void); 

typedef Boolean C*ATTCTl^^t>^C(»rLCTE> (void); 
typedef void UATTCTIJJPOAT^JTATE) (void); 

typedef struct < 

ATTCTLJCONSTRUCTOR Constructor; 

ATTCTl^COMFVT ^TORQUE CorputeTorque; 

AnCTl^DESTRLXrrOR Destructor; 

ATTaL^SJ«OEJC(m£TE IsHodeCaiplete; 
ATTCTLJJPOAT^JTATE IJpda t eState ; 

) ATTCTIJVTBL; 

/* RWA .mode structure: Only meaningful during RWA mode* */ 
typedef struct ( 

float TorqueCNUTl_WHEELS3; 

> ATTCTLJIWA; 

/* PCS mode structure: Only meaningful Airing PCS modes */ 
typedef struct < 

Unsigned16 CountsCNUTlJHRUSTERS:; 

> ATTCTtJ’CS; ; 

/#*** Abstract controller class 

typedef struct C 

ATTCT1JJWA Rwa; 

ATTCTIJKS Pcs; 

ATTCTLVTBL Function; 

> ATTCTLjCLASS; 


void AttCtljCaipjteT 6 rqMe(vo 1 d) < 

// Load INPUT structure uith Pleasured BodyRate, Wheel Speed, &jn Angle 
// Load INPUT structure with estimated and contended attitude 
// Call AutDCode Execute (WUT,OUTPUT) 

(♦AttCtl. Functi on. CoaputeTorqueK); // Call RWA/PCS virtual Con*xiteTorque 
function 

// Load AttCtl .SysMoaMag using 0 U 1 WT dSta 

> /* End AttCTljaxnputeTocqueO */ 
void AttCtl JbaCooputeTorque(void) < 

// Load AttCtl. Rwa structure using Autocode's OUTPUT 

> /♦ End AttCtl^RweComputeTorqueO */ 
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MAP's mission is to probe conditions in the Mrly universe by measuring the properties 
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direct approach. For early builds, 
autocode is being unit tested as a black 
box on a PC using test data captured 
from HIF1 without full path (white 
box) testing. For the final build, full 
path unit testing on the flight hard- 
ware wilt be performed. This 
approach allows us to take advantage 
of the quick design-to-test time for 
early builds when algorithmic changes 
are most likely to happen. However, it 
is based on the assumption that the 
full path unit testing will not uncover 
substantial coding problems late in 
the project schedule. 

Lowering the barrier 

Autocode has forced us to formally 
define our controller subsystem inter- 
face because it’s a separate physical 
and logical entity. We may not be 
exploiting all of the features of 
autocode but limiting the scope has 
served us well in terms of meeting 
schedule and mitigating risks. 
Autocode has affected our traditional 
way of doing business. On previous 
missions, the software engineers have 
worked fairly independently of the 
controls analysts, using an algorithms 
document as a formal communica- 
tions mechanism. Autocode has suc- 
cessfully lowered the cultural barrier, 
bringing the software engineers into 
the controls analysis environment, and 
the controls engineers have become 
more cognizant of the flight software 
environment. This symbiotic relation- 
ship helps scheduling since the depen- 
dency flow is no longer unidirectional 
from the analysts to the software devel- 
opers. 


I consider this project to be transi- 
tional with regard to how future pro- 
jects may be developed. Advances in 
flight software architectures, coupled 
with advancements in onboard com- 
puting resources, should allow for 
object-based software construction. 
Standardized object communications 
mechanism such as COKBA may be a 
viable option for flight controllers as 
they mature. The Distributed Object 
Computing group at Washington 
University is a good example of the 
work being done in this area.* 

Once a business establishes an 
object communications layer, reusable 
object libraries can be developed. 
Reusable objects may be archived in a 
format that is usable with respect to a 
developer. For example, a reusable 
controller written in C does not have 
much value to analysis that work in a 
graphical environment. The analysis 
would prefer to have a reusable con- 
troller in a form that can be easily 
manipulated within their develop- 
ment environment. Autonomous code 
generation tools would allow reusable 
libraries to exist in different formats, 
as long as the tools produce objects 
that conform to an object communica- 
tions standard. Regardless of what the 
future may hold, the design of high 
quality interfaces will be a critical fac- 
tor in successfully developing and 
using object libraries. MAP's design is 
first step towards achieving this goal. 

David MrComa's bio w\U. go n ght here. 
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Executable code related to th* article Is available at 
www .embtddtd.com. 
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